tests/internal/thread_storage.c (1)

13-30: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Consider adding multi-threaded coverage.

This test validates the single-thread get/set/init sequence, but the actual fix addresses pthread_once-guarded concurrent key initialization across multiple threads. A test spawning several threads that call FLB_TLS_GET/FLB_TLS_SET concurrently would more directly cover the race this PR fixes.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/internal/thread_storage.c` around lines 13 - 30, The current
test_thread_storage_get_before_init only covers a single-thread get/set/init
flow and does not exercise the pthread_once-protected concurrent initialization
path. Add a new multi-threaded test around thread_storage_ctx that spawns
several threads and has them call FLB_TLS_GET and FLB_TLS_SET concurrently, then
assert the TLS key is initialized safely and the values remain consistent across
threads.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

tests/internal/thread_storage.c (1)

34-41: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

Shared condition variable can still hang the test

The same cond is used for both the "ready" (worker→main) and "start" (main→workers) phases. At line 36, pthread_cond_signal wakes only one waiter. If a previously-created worker (waiting at line 39 on start == FALSE) consumes the signal instead of main (waiting at line 103 on ready < created), the signal is wasted. After the last worker signals, ready == created but main may still be asleep in pthread_cond_wait with no remaining signals to wake it — deadlock.

This was previously flagged and marked addressed, but the current rewritten file still uses pthread_cond_signal at line 36. Changing to pthread_cond_broadcast ensures main is always woken.

🔒 Proposed fix: broadcast instead of signal on worker ready

     pthread_mutex_lock(thread->lock);
     (*thread->ready)++;
-    pthread_cond_signal(thread->cond);
+    pthread_cond_broadcast(thread->cond);

#!/bin/bash
set -euo pipefail

# 1. Confirm the current worker-side signal is still pthread_cond_signal (not broadcast)
echo "=== Worker-side signal (expect pthread_cond_signal) ==="
sed -n '34,41p' tests/internal/thread_storage.c

# 2. Confirm main-side wait and broadcast
echo "=== Main-side wait/broadcast ==="
sed -n '101,107p' tests/internal/thread_storage.c

# 3. Verify the test file is registered in the build
echo "=== CMakeLists registration ==="
rg -n 'thread_storage' tests/internal/CMakeLists.txt

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/internal/thread_storage.c` around lines 34 - 41, The worker-to-main
ready notification in thread_storage.c still uses pthread_cond_signal, which can
wake the wrong waiter and leave main blocked in the ready wait. Update the
synchronization in the worker setup path around the pthread_cond_signal call in
the thread helper so it uses pthread_cond_broadcast instead, ensuring any main
thread waiting on the shared condition variable is always awakened while
preserving the existing ready/start handshake in thread->ready and
thread->start.